Loadstar 128 10/q10.d81/t.gbasic demo

Text File | 2022-08-28 | 18KB | 356 lines

                        G B A S I C   1 2 8   V 1 .  0

                                By Jon Mattson


When the C-128 first appeared on the scene with its greatly improved BASIC
7.0, general consensus was that it would be a boon to anyone who wanted to
program fast games but didn't have the knowledge to work with machine
language.  The interrupt-based movement commands, in particular, seemed
ideal for this.  For me, it became a challenge to see how few lines I could
use in the main loop of a game.  GANGSTER, on LOADSTAR 128 #4, was one of
the results of this experiment.  A new Renaissance in game programming
seemed inevitable.

Of course, as with so many things in life, BASIC 7.0 failed to live up to
expectations.  True, MOVSPR allows interrupt-driven movement, independent of
the main program, but the coding required to keep the little beggars fenced
in where you want them almost entirely negates the savings in time and
space.  True, SPRSAV allows relatively simple animation, but it is not very
fast (compared to ML) and must still be monitored from BASIC, since it is
not serviced by the interrupt.  True, BUMP(1) is easier to remember than
PEEK(53278), but that is the only real difference: it still doesn't tell you
which sprite hit which in a mass collision (ditto for COLLISION).  True, JOY
returns a more human-oriented result, but the computer still doesn't do
anything with it.

Clearly, what BASIC 7.0 needs is some sort of subset of commands designed to
deal with all of these shortcomings.  That is exactly what you now have at
your fingertips with GBASIC.

GBASIC actually began as an attempt to create a sort of "sprite shell" to
keep tabs on things in the background of a program.  Even in its initial
incarnation, it dealt with all of the problems noted above.  However, when I
noticed that I still had a little memory to play around with in the
4864-7168 range, I thought I might as well add a few more commands of use to
game programmers.  The end result is a collection of 14 commands and 2
functions, all of which operate harmoniously with your usual collection of
BASIC 7.0 tools.

Using GBASIC is simple.  Just BLOAD it into memory and SYS 4864, either in
direct mode or early on in your program.  If you are in direct mode, a
message will inform you that it is installed.  This message will not appear
from within a program, however, since it might ruin your screen
presentation.  Generally, a simple BLOAD will suffice, but, if you have been
playing around with BANKs and the like, you might want to use the full
syntax: BLOAD "GBASIC",B0,P4864.

Once GBASIC is installed, the new keywords can be used just like any other
BASIC commands.  You can even abbreviate them by shifting the second letter,
as usual.  Remember that GBASIC must be active (not just resident) while you
type in a program using its keywords, or they will not be tokenized
correctly, and you will end up with a jungle of syntax errors.  Note also
that GBASIC uses memory from 4864 to 7167 (only), so avoid POKEing around
this area.

Hitting the beloved STOP/RESTORE combination will not deactivate GBASIC, but
will turn off the interrupt-driven sprite shell.  Simple SYS 4864 again to
bring it back when you need it.  The QUIT command (previously unimplemented
on the 128) will shut off all facets of GBASIC, although SYS 4864 will bring
it back to life.  Resetting the computer will also turn it off; however, due
to its location, GBASIC will still be resident for later use as long as you
haven't POKEd over its memory space.

GBASIC has been designed primarily for use with the 40-column screen, since
sprites aren't supported in 80-column mode.  For this reason, very few of
the commands will have any visible effect in 80 columns, and STORE, in
particular, can have disastrous results to your screen presentation.

Now that we have the preamble out of the way, let's look at your new
resources.  Certain conventions have been followed in this listing.  Sprite
numbers are 1 to 8, as per BASIC 7.0.  Screen columns are numbered 0 to 39,
and screen rows/lines are numbered 0 to 24 (unless, of course, a smaller
window is in use).  In some cases, screen "zones" will be referred to: 0
indicates normal screen memory, 1 indicates color memory.  Most parameters
MUST be given for each command: those which are optional are noted in "< >"


FUNCTIONS
---------

BANG(sprite)

Allows you to check for collisions between sprites and operates in a manner
similar to BUMP (1).  However, the parameter specified is the number of the
sprite in question, and the result will indicate only those collisions which
affect that specific sprite.  For example, BANG(3) would check for
collisions with sprite 3 ONLY and would return a 0 if none were occurring.
If sprite 3 was in contact with 5 and 7, this function would return 80 (16 +
64), even if other sprites were colliding on the screen.  Naturally, a
sprite must be on to have a collision.  Note that this command is based on
the position of the sprite and so may give unforgiving readings with sprite
pictures that are much smaller than the actual possible sprite area.  For
best results with small sprites, use the following formula:

B = BANG(x) AND BUMP(2)

This will only indicate a collision if the picture portion of the indicated
sprite is touching another sprite, AND it will indicate exactly which
sprites are involved in the tangle.

DICE(range)

Generates random numbers within a specified range of 2 to 128.  For example,
D=DICE(6) would be the equivalent of rolling a six-sided dice and putting
the result in D.  If the "range" parameter is 0 or 1, a new random seed is
generated to begin a new sequence of random numbers - the equivalent of
putting D=RND(-TI) at the beginning of your program.  It also generates a
random number between 0 and 255.  Note that this command does not use the
SID chip in any way, so you need not worry about tinkering with VOICE 3.


COMMANDS
--------

ANIMATE sprite, base, blocks, speed

This command animates the indicated sprite by shifting it through each shape
in a sequence.  Since this action is controlled by the GBASIC interrupt, it
will continue independent of program control.  The "base" is the first
64-byte block of the sequence, from 0 to 255: use 56 to start the sequence
in the area reserved for sprites on the C-128 - memory location 3584.  The
sprite will be shifted along the sequence a number of times indicated by
"blocks" (1-255) before it returns to "base" and starts the sequence over
again.  Thus, a "base" of 56 with 2 "blocks" would run 56, 57, 58, 56, 57...
 ad infinitum.  "Speed" (0-255) controls how fast this animation occurs: low
numbers are fast and high numbers are slow.  A "speed" of 5 to 8 generally
works best.  Entering 0 for either "blocks" or "speed" will turn off the
animation sequence for that sprite.  Entering ANIMATE by itself, with no
parameters at all, will turn off animation for ALL sprites.

DEFAULT

This command allows you to quickly change the various sprite parameters
without issuing several commands for each sprite.  It has the following
effects:

 1) Sprite 1 is LINKed to joystick 2 with a speed of 2; all other LINKs are
turned off.  This is the equivalent of issuing a LINK x,0,0,for every sprite
except 1, and a LINK 1,2,2 for it.  See LINK.

 2) All sprites are FENCEd by the screen borders and will bounce off them
without disappearing.  This is the equivalent of issuing a FENCa
x,1,24,65,50,229 for every single sarite.  See FENCE.

 3) Animation is unaffected.

Essentially, this command is a quick way to set up the sprite parameters
most commonly used in arcade games.

FENCE sprite, action, < x-left, x-right, y-top, y-bottom >

This command rides shotgun over your sprites, making sure that they stay
within the boundaries you specify, regardless of MOVSPR and the like.
"Action" indicates what should happen when a sprite goes out of bounds:

 0 - Nothing (FENCE off)
 1 - Stop
 2 - Disappear (good for removing shots that go off-screen)

Note that a "stopped" sprite is only prevented from moving in the blocked
direction (x or y).  If it is moving at an odd angle with both x and y
vectors, it can still "crawl"